Method and apparatus for dynamically reconfiguring a server system

ABSTRACT

A method and apparatus for dynamically reconfiguring a server system. When a new server configuration is applied, a previous server configuration is saved. When receiving a service request, a first server is selected by using a first scheduling algorithm according to the new configuration. If the selected server is incorrect, a second server is selected by using a second scheduling algorithm according to the saved previous server configuration. User data associated with the received service request is moved from the second server, if correct, to the first server. In this way, stored data will be gradually and dynamically reorganized from the previous configuration to the new configuration in a relatively simple way.

This application is the US national phase of international applicationPCT/SE02/01279 filed on 27 Jun. 2002, which designated the US and claimspriority to SE Application No. 0200417-4 filed 13 Feb. 2002. The entirecontents of these applications are incorporated herein by reference.

TECHNICAL FIELD

The present invention relates generally to a method and apparatus forreconfiguring a server system comprising a plurality of servers forproviding communication services. In particular, the server system isreconfigured dynamically such that shut-down periods for one or moreservers can be avoided or at least be minimised.

BACKGROUND

A multitude of different fixed and mobiletelecommunication/datacommunication services have been developed, inaddition to traditional voice calling and short text messaging. Forexample, Internet browsing has rapidly become very popular, and inrecent years the wireless domain has converged with the Internet. Mobileterminals are now available having functionality for connecting to theInternet over a wireless access network to obtain information andservices from sites and servers located anywhere throughout the world.

Moreover, new technologies for mobile communication are introduced,providing greater network capacity and higher transmission bit rates. Inparticular, GPRS (General Packet Radio Service) and WCDMA (Wideband CodeDivision Multiple Access) networks are currently emerging for enablingwireless data services that require a wide range of different datarates. The data communicated in many new services may include voice,text, images, audio files and video files in various different formatsand combinations.

By way of example, mobile instant messaging, commonly known as“chatting”, and presence services are rapidly becoming popular. Instantmessaging is known from the world of fixed PCs (Personal Computers),including message status reporting and various group and contact listfeatures. Presence services involve information on the location ofmobile terminals and enable users to receive messages according to theirprofile and availability. A user profile can be personal and may bedefined by preferences, interests and hobbies, as well as more temporaryfactors, such as user availability and current moods. Messages andcontent services can also be delivered depending on the presentlocation, availability and terminal capabilities. It can be readilyunderstood that such services require the storage of considerableamounts of retrievable user-specific data, which in many cases need tobe frequently updated due to their dynamic nature.

The demands for telecommunication services are thus increasing rapidly,and service providers are established all over the world, equipped withhardware and software resources to meet these demands. In particular,means for processing service requests and data, as well as means forstoring huge amounts of data are needed. Consequently, a serviceprovider must be able to efficiently control the processing and storingmeans which typically comprise a system of different service componentssuch as servers. The expression “server” will be used hereafter torepresent any hardware and/or software for storing and/or processingdata. A server may be configured to provide one or more specificservices.

For an Internet service provider or the like controlling a plurality ofservers, processing and storing load must be distributed over theservers. This is necessary in order to efficiently utilise availablecomputing and storing resources, and to handle hotspots and avoidbottlenecks. As mentioned above, large amounts of data must be storedand should also be easy to find and retrieve.

As seen from the examples of services given above, different types ofstored data may be of a very dynamic nature, needing frequent updating.Moreover, server systems must be reconfigured from time to time as theprocessing and storing load change, e.g., due to changing demands ofservice requests, added or removed subscribers and the introduction,modification or deletion of services. The workload on servers mayincrease rapidly so that individual servers are easily overloaded, atleast for a short time, in particular popular web servers. To overcomeoverloading problems in servers; basically two solutions are available.

Firstly, an existing server may be upgraded to increase its computingand/or storing capabilities. However, the server will soon becomeoverloaded again if the amount of service requests and/or needs for datastorage continue to increase. Further upgrading is then required, whichcan be complex and costly to perform.

Secondly, it is possible to add further servers to meet a higher load.The concept of virtual servers has been proposed to provide load sharingbetween plural servers. A virtual server is a scalable server built on acluster of real servers, which is transparent to end users such that theusers see only a single virtual server. The front-end of the realservers is a node, sometimes referred to as a “load balancer”,configured to schedule service requests to the different real servers.Incoming service requests may involve processing tasks and storing tasksto be performed by the servers. Scalability can thus be achieved bytransparently adding or removing servers in the cluster.

However, it is a problem to efficiently distribute processing andstoring tasks between a plurality of servers, yet enabling easyretrieval of stored data. “Processing tasks” may involve analysingservice requests, processing of data and running certain applicationsfor delivering requested services. “Storing tasks” may involve storingnew client-specific, session-specific or configuring data, updatingalready stored data, and retrieving stored data. For example, a servicerequest may require the retrieval of certain data which is used as inputfor executing a specific processing task or service application. Clientdata and session data is hereafter collectively referred to as “userdata”.

In current solutions involving the distribution of processing andstoring tasks, a server is often allocated to a client upon a loginrequest. The allocation scheme used for selecting a server is normallybased on the current load on a predetermined set of servers, such thatthe server having the lowest current load, with respect to memoryresources and/or CPU (Central Processing Unit) capability, etc, isselected for a client or session. Server allocation is typicallyperformed by using a central load manager node or the like. Stored userdata must then be retrievable, i.e. it must be possible to find theserver in which the searched data was stored.

The most simple current solution for selecting a server is to use a“Round Robin” allocation scheme. Further load sharing solutions areknown which are more complex, such as “Weighted Round Robin”, “LeastConnection”, “Weighted Least Connection”, “Locality Based LeastConnection”, “Destination Hashing” and “Source Hashing”.

However, the solutions mentioned above are relatively complex to use,resulting in problems related to supervision, operation and maintenance,since it is difficult to predict where data will be distributed andstored. Furthermore, it may be difficult to find and retrieve data beingstored in one or more servers if no reference or pointer to the data isstored as well. A client performing a login may have a proper referenceto the data, but no other client or device can find and retrieve thedata without the reference, unless so-called “brute force searches” areused among a set of servers.

“Round Robin” scheduling is only suitable for distributing processingload, since processing tasks are not affected by in which server theyare performed. On the other hand, retrieving stored data in one of moreservers carrot be done by using Round Robin but requires the use ofspecific pointers or references as described above. Furthermore, acommon basic problem with some of the other scheduling methods mentionedabove is that they use is (Internet Protocol) addressing for scheduling.Since a plurality of clients can reside behind a single IP address(proxy, NAT, etc.), these can neither be used for data distribution norload sharing.

Storing tasks are therefore preferably scheduled by means of a hashingalgorithm using some client or session identity as input. The hashingalgorithm then provides a number identifying a selected server. If thesame hashing algorithm is used again when retrieving data on a lateroccasion for the same client or session, the same server will beselected, provided that the servers have not been reconfigured since thesearched data was stored. Thereby, the need for using specific pointersor references is eliminated.

However, if the number of servers and/or the identities of individualservers are changed in a reconfiguration operation, the hashingalgorithm will most probably not provide the correct server identityanymore, if user data for a specific client or session was stored beforethe reconfiguration was made. A current solution for avoiding thisproblem is to shut down the server system from service requests formodifying the hashing algorithm and moving stored user data betweenservers, such that server selection becomes correct. This is a quitecumbersome and time consuming operation, which is undesirable sinceservice requests cannot be attended meanwhile, resulting in lost revenuefor the service provide. Moreover, the reconfiguration operation isrelatively complex involving a considerable risk for errors.

SUMMARY

The object of the present invention is to reduce or eliminate theproblems outlined above, and to provide dynamic and efficientreconfiguration of a server system during simultaneous handling ofservice requests. Thereby, shut-down periods for one or more servers canbe avoided, or at least be minimised.

These objects and others are obtained by providing a method andapparatus for dynamically reconfiguring a server system. The serversystem comprises a plurality of servers being capable of performing atleast one common storing task, and a scheduling unit configured toselect servers for handling incoming service requests.

A new server configuration is applied, and a previous serverconfiguration is saved. When a service request is received, a server isselected for handling the received request by using a first schedulingalgorithm according to the new configuration. If the selected server isincorrect, a server is selected in a second attempt by using a secondscheduling algorithm according to the saved previous configuration. Ifthe correct server is selected by the second scheduling algorithm, userdata associated with the received service request is moved from theselected server to the server selected by the first schedulingalgorithm. If the selected server is also incorrect in the secondattempt, a server can be further selected by using a schedulingalgorithm according to a saved even earlier configuration.

Preferably, the scheduling algorithms are hashing algorithms. Using thehashing algorithms may include deriving a hash number from a user ID andcalculating a server ID number from the derived hash number. Thefollowing algorithm may then be used:server ID=hash(user ID)modulo n  (1)where n is the number of possible servers, and the modulo operatorproviding an integer between 0 and n−1. The new configuration mayinvolve a changed number of servers, and in the second schedulingalgorithm, n is then changed accordingly from the first schedulingalgorithm.

The service requests may involve storing tasks such as storing new data,updating already stored data, and retrieving stored data.

Applying a new server configuration may further include storing newconfiguration data in a central administrator or the like, which can beaccessed by the servers. Each server may comprise a local administratoror the like, being adapted to receive new configuration data from thecentral administrator. New configuration data can be pushed from thecentral administrator to the servers, or be retrieved by sending arequest from a server. The central administrator may comprise means forpushing new configuration data to one or more servers. Further, thelocal administrator may comprise means for sending a request for newconfiguration data to the central administrator.

The procedure may further be executed using a computer programcomprising a software code being adapted to perform the method in aserver system.

The technology described here is capable of simultaneously handling adual configuration of a server system. When the system is to bereconfigured by adding and/or removing one or more servers, the previousold configuration is saved. Thereby, requested data can be retrieved byusing the old configuration, if the requested data could not be found byusing the new configuration.

Stored data is gradually and dynamically re-organised from the oldconfiguration to the new one with a minimum of impact on the systemoperation. A better distribution of data may also be achieved whenreconfiguring a server system, since data associated with new users orsessions can be efficiently distributed on existing servers as well ason any new added servers.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a schematic overview of a communication scenario.

FIG. 2 is a block diagram of an exemplary server system according to oneexample embodiment.

FIG. 3 is a flow chart illustrating a procedure for handling a servicerequest.

FIG. 4 is a block diagram illustrating centralised administration ofconfiguration data.

DETAILED DESCRIPTION

In FIG. 1, a schematic communication scenario is illustrated in whichthe present invention can be used. A plurality of client terminals 100are connected to a backbone network 102, such as the Internet. Theclient terminals 100 may be fixed or mobile, such as wired terminals, orwireless terminals connected to a mobile access network 104 over an airinterface, as Indicated in the figure. A plurality of service providers106 are likewise connected to the backbone network 102, each comprisingone or more servers for executing telecommunication services requestedfor the client terminals 100. In reality, various further networksand/or nodes are typically involved in communication routes betweenclients and service providers, although not shown here for the sake ofsimplicity.

A client terminal 100 may initiate a specific telecommunication serviceby sending a service request over the backbone network 102 to a serviceprovider 106. The contacted service provider then activates one or moresuitable service applications in response thereto. Activating a serviceapplication may involve various processing and storing tasks, asperformed in one or more servers. A service application may also betriggered without a preceding terminal request, such as through a “push”mechanism as used for example in the context of WAP (WirelessApplication Protocol). A service request may thus originate from anotherservice provider or network operator, e.g. needing user data of acertain client or ongoing session. For example, a service provider maywant to transmit certain information to mobile stations as they enter aspecific area. In that case, the service provider will request neededuser data, such as terminal capabilities and client profile, e.g.,including predefined preferences and interests.

As mentioned earlier, service providers are typically equipped with aplurality of servers in order to handle service requests from clientsand other service providers. Thus, the same functionality is duplicatedin several servers, thereby being capable of performing the same orsimilar service tasks simultaneously for plural clients, be itprocessing or storing tasks. The technology described in this caseenables efficient reconfiguration of plural servers such that anyshut-down periods can be avoided or at least be minimised.

In FIG. 2, a simplified server system 200 is illustrated for providingone or more telecommunication services for client terminals. The serversystem 200 comprises a scheduling unit 202 for scheduling incomingservice requests involving one or more storing tasks. The schedulingunit 202 is connected to a set of servers 204 that are capable ofperforming at least one common storing task. The servers 204 may inaddition be capable of performing other tasks or operations as well,which is however not within the scope of the present invention. Theservers 204 may further be designated for different serviceapplications, and may comprise for example Session servers, InstantMessaging servers, Presence servers etc. The server system 200 may alsoinclude further components such as access nodes and different serversdesignated for different request handling operations.

The scheduling unit 202 may reside in an access rode of a serviceprovider, receiving service requests from clients, service providers ornetwork operators. The scheduling unit 202 may also reside in aprocessing server being configured to forward certain service requeststo other servers for further treatment.

The scheduling unit 202 is configured to use scheduling algorithms forselecting specific servers 204 for incoming service requests, using somepredefined client or session identity as input. A scheduling algorithmthen provides a number identifying a selected server. The schedulingalgorithm provides that when stored data for a client or session isretrieved, the correct server will be selected, if the number of servers204 and their identities are the same as when the searched data wasstored. Further, if a storing task involves storing new user data, thescheduling algorithm will provide that the new data is stored in thesame server as old user data was stored, thereby collecting all userdata for a specific client or session in the same server.

The scheduling algorithms used are preferably hashing algorithms. Ahashing algorithm means that a hash number is derived from apredetermined identity code of a client or a session, which willhereafter be collectively referred to as a “user ID”. A server identitycan be determined by calculating a corresponding server ID number bymeans of a predetermined algorithm or formula based on the derived hashnumber. For example, the hash number can be a simple checksum or thelike for a binary code of the user ID. According to one example, aserver 204 is determined to perform a storing task from the followingalgorithm:server ID=hash(user ID)modulo n  (1)where n is the number of possible servers in the set. The modulooperator will provide an integer between 0 and n−1. For example, if foursecondary servers 204:0-204:3 are available, i.e. n=4, and oneparticular client gives hash(user ID)=14, the server ID=2. Thus, server204:2 is selected accordingly. For another client, hash(user ID)=16,leading to server ID=0, and so forth. Any suitable hashing function maybe used on a user ID, provided that the same server ID is always derivedfrom the same user ID. In this way, storing load can be distributed inthe set of servers 204.

However, if the server system needs to be reconfigured by changing thenumber of servers, the used hashing algorithm must also be modified inorder to distribute storing load between the new number of servers.Thus, it may be necessary to add or remove one or more servers due to,e.g., trends of service demands, or changes in subscribers and offeredservices.

For example, if the above-described hashing algorithm (1) is used, nmust be changed according to the new number of servers. Thereby,inputting a user ID in the modified hashing algorithm will most probablyprovide a different server ID than before.

In previous solutions, a reconfigured server system is shut down for aperiod of time in order to move storage or user data, or to introduce aspecific pointer or reference to the relevant storage place for eachaffected data entry in she concerned servers. It can be readilyunderstood that this is a tedious and time consuming procedure.

Instead, the dynamic solution presented here allows simultaneousoperation of handling service requests, thereby avoiding unwantedshutdown periods. When introducing a new server configuration, thehashing algorithm is modified according to the new configuration, andthe old configuration is saved in a memory 206 in the scheduling unit202. Saving the old configuration includes saving at least the oldhashing algorithm and its parameters, and possibly also information onthe server system structure of the old configuration.

When receiving a service request involving a storing task for a clientor session as identified by a user ID, the scheduling unit 202 makes afirst attempt to find the correct server by using the modified newhashing algorithm. If the expected server is not found, i.e. the serverwhere searched data or old user data was stored, the old hashingalgorithm according to the saved old configuration is used in a secondattempt.

When the correct server is found and selected for the storing task, dataassociated with the concerned client or session is moved from thatserver to a new server corresponding to the new hashing algorithm. Ifthe new hashing algorithm happens to select the same server as the oldhashing algorithm, the data will of course remain there.

In this way, already stored data can be gradually moved to correctservers in accordance with the new hashing algorithm whenever servicerequests are received for different clients or sessions. In the courseof time, a growing share of the total data amount will end up in correctservers according to the new configuration. Finally, it may beappropriate to shut down the server system during a limited period oftime for changing storage of any remaining user data which has not yetbeen moved. The old configuration can then be deleted from the memory206.

It should be noted that it is possible to use more than twoconfiguration versions simultaneously in a server system. Thus, furtherprevious configurations of even earlier versions may be saved in thememory 206. In that case, more than two attempts can be made for findingthe correct server, by using saved even earlier configuration versions.

An example procedure of dynamically reconfiguring a server system willnow be described with reference to a flow chart shown in FIG. 3,occasionally also referring to FIG. 2. It is assumed in this examplethat the number of servers has been changed and a new hashing algorithmhas replaced a previous one, which has been saved in a memory 206. In afirst step 300, a service request is received in a scheduling unit 202.It is detected that a storing task must be executed for the servicerequest in one of the servers 204, such as retrieving already storeduser data. In a step 302, a first attempt is made to find the correctserver where the searched data is stored. The new hashing algorithm isthen applied to select a server for the received service request, usinga corresponding user ID as input. The user ID can normally be extractedfrom the received service request.

Next in a step 304, it is determined whether the correct server wasfound and selected in step 302 by the new hashing algorithm. If so, thestoring task can be executed accordingly in a step 306, after which theprocedure may return to the first step 300 for receiving a next servicerequest. If it is determined in step 304 that the selected server wasincorrect, a second attempt is made to find the correct server in a step308, by applying a saved previous hashing algorithm on the receivedservice request.

It is then determined in a next step 310, whether the correct server wasfound and selected in step 308 by the previous hashing algorithm. If so,user data associated with the service request is moved, in a step 312,from the old server to the new server selected in step 302 by the newhashing algorithm. The moved data may embrace all user data of a clientor session for which the service request was directed, even if thestoring task to be performed is concerned with only some of that data.

The storing task is also executed accordingly in a step 314, after whichthe procedure may return to the first step 300 for receiving a nextservice request. It should be noted that steps 312 and 31 can beperformed in reverse order, if suitable. For example, it may beefficient to first retrieve searched data in a storing task beforemoving the data to another server.

If it was determined in step 310 that the correct server was still notselected in step 308, it may be determined in a step 316 whether a newattempt should be made to find the correct server. If so, the procedurereturns to step 308 for applying a further previous hashing algorithm,which may be an even older saved hashing algorithm, as explained above.If determined in step 316 that no new attempt is to be made, e.g. due totime-out or count-out, the storing task cannot be performed for thereceived service request. A new request may then be received byreturning to the first step 300.

As mentioned above, reconfiguring a server system may involve changes inoffered services. For example, new services may be added and presentservices may be modified or omitted. In a system with plural servers,such reconfiguration requires that all servers are updated with the newconfiguration. In previous solutions, relevant new configuration data isstored in all servers. In the present invention, all configuration datamay instead be stored in a central administrator or the like, which canbe accessed from the servers.

In FIG. 4, a schematic block diagram illustrates a centralisedadministration of configuration data. A group of servers 400 is shown,each being capable of handling at least one common service request, suchas the servers 204 in FIG. 2. Each server 400 comprises a localadministrator 402 which is connected to a central administrator 404 andhaving functionality for accessing configuration data there from. Thecentral administrator 404 may be a separate node in the server system ormay reside in an access node or in a server, e.g. together with ascheduling unit 202 as described above.

The servers 400 may need access to certain configuration data in orderto invoke requested services. However, no such configuration data isstored locally in the servers according to one embodiment. Instead, allconfiguration data being valid for the servers 400 is stored in thecentral administrator 404. Thus, any configuration data required forinvoking a requested service in a server 400 can be retrieved from thecentral administrator 404 by sending a request for the configurationdata from its local administrator 402. Only a reverence to the centraladministrator 404 is needed in the local administrators 402.Configuration data can also be “pushed” to one or more localadministrators 402 from the central administrator 404, i.e. without apreceding request from the local administrators 402.

By this arrangement, configuration data is efficiently stored in onlyone place instead of being duplicated in the servers 400. Any updatingof configuration data can easily be done in the central administrator404, which will have an accurate overview of all current services andservers. Errors and conflicts between servers having differentconfiguration versions can thereby be avoided. Moreover, the need forsynchronous updates in plural servers is eliminated.

The technology may be used to great advantage in telecommunicationservices defined in the context of “Wireless Village Server”, such asthose relating to Instant Messaging, Presence Information and SharedContent. By using the invention in servers for handling such servicerequests, a dynamic and efficient reconfiguration is achieved for thoseservers. However, the technology is also applicable to any scalablesystems for data distribution. By using this technology, servers canthus be dynamically added and/or removed without shutting down theserver system, at least for extensive time periods. In this way, a highlevel of service can be maintained.

In particular, the technology can advantageously be used in a serversystem for distributing data storage and processing load between pluralservers which is described in Applicant's co-pending U.S. applicationSer. No. 10/504,128, filed Aug. 11, 2004. In this solution, a primaryserver for performing a processing task is assigned using a firstscheduling algorithm, which is capable of selecting any primary server.A secondary server for performing a storing task is assigned using asecond scheduling algorithm, which is capable of selecting a specificsecondary server corresponding to a client involved in that storingtask.

While the technology has been described with reference to specificexemplary embodiments, the description is only intended to illustratethe inventive concept and should not be taken as limiting the scope ofthe invention. Various alternatives, modifications and equivalents maybe used without departing from the spirit of the invention, which isdefined by the appended claims.

1. A method of dynamically reconfiguring a server system comprising aplurality of servers for handling incoming service requests involvingone or more storing tasks, each server locally storing different userdata at that server in a first server configuration, comprising thesteps of: A)—applying a second different server configuration where anumber of the servers is different from the first server configuration,B)—saving the first server configuration, wherein the following furthersteps are executed by a service request scheduling unit when receiving aservice request: C)—selecting a server for handling a received servicerequest by using a first scheduling algorithm according to the secondserver configuration with a client or session identity of the receivedservice request as input, D)—selecting a server by using a secondscheduling algorithm according to the first server configuration savedin step B) with the client or session identity as input, if the serverselected in step C) was incorrect by not having locally stored user dataassociated with the received service request, and E)—moving user dataassociated with the received service request from the server selected instep D), using the second scheduling algorithm, if the server selectedin step D) is correct having locally stored the user data associatedwith the received service request, to the server selected in step C)using the first scheduling algorithm.
 2. A method according to claim 1,comprising the further step of selecting a server by using a thirdscheduling algorithm according to a saved even earlier configuration, ifthe server selected in step D) using the second scheduling was alsoincorrect.
 3. A method according to claim 1, wherein the first andsecond scheduling algorithms are hashing algorithms.
 4. A methodaccording to claim 3, wherein using the hashing algorithms includesderiving a hash number from a user ID and calculating a server ID numberfrom the derived a hash number.
 5. A method according to claim 4,comprising wherein the hashing algorithm is:server ID=hash(user ID)modulo n  (1) where n is the number of possibleservers, and the modulo operator providing an integer between 0 and n−1.6. A method according to claim 5, wherein the second serverconfiguration involves a changed number of servers, and that in thesecond scheduling algorithm, n is changed accordingly from the firstscheduling algorithm.
 7. A method according to claim 1, wherein theservice requests involve storing tasks.
 8. A method according to claim7, wherein the storing tasks include any one or more of: storing newdata, updating already stored data, and retrieving stored data.
 9. Amethod according to claim 1, wherein step A) of applying a second serverconfiguration includes storing new configuration data in a centraladministrator, which can be accessed by the servers.
 10. A methodaccording to claim 9, wherein new configuration data is pushed from thecentral administrator to one or more servers.
 11. A method according toclaim 9, wherein new configuration data is retrieved from the centraladministrator by sending a request from a server.
 12. An apparatus forreconfiguring a server system, the server system comprising a pluralityof servers each being capable of performing at least one storing task,and a scheduling unit configured to select servers for handling incomingservice requests involving one or more storing tasks, each serverlocally storing different user data, wherein the scheduling unit isconfigured to perform the following: apply a second different serverconfiguration where a number of the servers is different from the firstserver configuration, save the first server configuration, select afirst server for handling a received service request by using a firstscheduling algorithm according to the second server configuration with aclient or session identity of the received service request as input, andselect a second server by using a second scheduling algorithm accordingto the first server configuration, if the first server was incorrect bynot having locally stored user data associated with the received servicerequest, and wherein the apparatus further comprises means for movinguser data associated with the received service request from the secondserver, if the second server is correct having locally stored user dataassociated with the received service request, to the first server. 13.An apparatus according to claim 12, wherein the scheduling unit isconfigured to select a server by using a scheduling algorithm accordingto an even earlier configuration, if the second server was alsoincorrect.
 14. An apparatus according to claim 12, wherein thescheduling unit is configured to use hashing algorithms as schedulingalgorithms.
 15. An apparatus according to claim 14, wherein thescheduling unit is configured to derive a hash number from a user ID andcalculate a server ID number from the derived a hash number.
 16. Anapparatus according to claim 15, wherein the scheduling unit isconfigured to use the following algorithm:server ID=hash(user ID)modulo n  (1) where n is the number of possibleservers, and the modulo operator providing an integer between 0 and n−1.17. An apparatus according to claim 12, further comprising a centraladministrator for storing new configuration data, which can be accessedby the servers.
 18. An apparatus according to claim 17, furthercomprising a local administrator in each server for receiving newconfiguration data from the central administrator.
 19. An apparatusaccording to claim 17, wherein the central administrator comprises meansfor pushing new configuration data to one or more servers.
 20. Anapparatus according to claim 18, wherein the local administratorcomprises means for sending a request for new configuration data to thecentral administrator.
 21. A computer program product comprising asoftware code stored on a tangible medium for method of claim 1 in aserver system.